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ABSTRACT 


Graphical User Interfaces (GUI) are quickly becoming the standard operating environment for 
most software programs and operating systems. Ease of use, rapid learning and the ability to retain 
complex task sequences and operations are some of the advantages attributed to this type of interface. 
VxTien properly implemented the GUI can provide a natural interaction betvxeen the user and the 
computer. Initial acceptance and continued use of any program can be greatly enhanced by proper 
design of this interface It is expected that this trend toward visual representation of a task's objects 
and actions vsill be more fully developed and expanded in future years. This thesis explored the 
principles of interface desig'i with particular attentitm given to the specific characteristics associated 
with GUI desi,' Unique design concepts associated with Negotiation Support Systems were also 
considered. These design te^-hniques and principles were then applied in the analysis and design of 
the graphical user interface for a Bilateral Negotiation Support System based on multiple attribute 
utility thei'ry. The program was written in Microsoft Visual Basic for use under the Microsoft 
Windows 3.0 operating environment. 
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I. INTRODUCTION 


A. PURPOSE OF THESIS 

The purpose of this thesis is to design and implement a Graphical User Interface 
(GUI) based program for a Bilateral Negotiation Support System (NSS) (Bui & 
Sivasankaran, 1991). The program is written to operate on a Microsoft Windows/DOS 
operating system microcomputer. It is expected that graphical user interfaces, when 
properly implemented, can provide a user friendly and natural interaction betw'een the 
user and the decision support system program. Initial acceptance and continued use of 
any program can be greatly enhanced by proper design of the interface. 

B. BACKGROUND 

1. Bilateral Negotiation Support Systems (NSS) 

The framework upon which the Bilateral NSS is based was originally 
formulated in a publication on Group Decision Support Systems (Bui, 1987) and a 
publication on Bilateral Negotiation Support Systems (Bui. 1991). The first character- 
based, menu-driven Bilateral NSS program based on this design was written in the Pascal 
language in 1987 and subsequently translated to the C language in 1991. 

The Bilateral NSS is a multiple attribute, joint utility negotiation model. In 
its present form it supports a two party negotiation strategy. A negotiation session can 
consist of up to ten issues of contention. Within an issue, each party can assign relative 
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utilities within the range of values defined by the party's initial offers. Also, relative 
w-eightings can be assigned to each issue by the parties involved. Once party variables 
(weights, utilities and initial offers) are entered for both parties, negotiation results are 
calculated and displayed in tabular and graphical formats. 

2. Graphical User Interfaces (GUI) 

Over the past ten years, the Graphical User Interface has become the standard 
operating environment for most software programs. The beginnings of GUI design can 
be traced to research started in the 1970's at the Xerox Palo Alto Research Center. The 
result of this initial research was the introduction of a computer with a GUI interface 
called the Xerox Star 8010 workstation. It had a cursor-based interface using high 
resolution graphics and icons. (Norton, 1990) 

The next evolution in GUI design w'as begun by the Apple Computer 
Corporation. Apple designed and introduced the Lisa Computer in 1983 after visits to 
the Xerox Palo Alto Research Center by key corporate personnel. Although not 
commercially successful, it was the precursor for the successful introduction of the 
Macintosh Computer in 1984. Most people today credit the Apple Macintosh as starting 
the "GUI revolution." 

Realizing the potential importance of the GUI design, Microsoft Corp)oration 
began work on their own GUI and introduced the Windows GUI environment in 1985. 
Several revisions of this GUI followed until the commercially successful release of 
Windows 3.0 in 1990. At the time of this writing. Microsoft is releasing an updated 
version of Windows 3.0 - Windows 3.1. It is expected that the GUI-based Bilateral NSS 
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developed for this thesis will run faster with Windows 3.1. This current version, along 
with the Microsoft Disk Operating System (DOS), is the environment under which the 
Bilateral NSS w-as developed. 

C. LITER.4TLTIE REVIEW AND METHODOLOGY 

The initial thrust in researching for this thesis was in gaining a basic perspective 
on designing the user interface for NSS. Several publications on general interface design 
were reviewed (Lim &. Benbasat, 1991). These publications discussed a broad Sf)ectrum 
of design techniques on graphical interfaces as well as the character-based interfaces such 
as menus and command line entry. With a basic understanding of interface design, the 
next step was getting information on GUI design for the IBM-PC/Windows platform. 
The primary publication used was the Common User Access Advanced Interface Design 
Guide (IBM, 1989). This document provides a set of interface standards for all Windows 
programmers to follow . 

After gaining an initial feel for interface design techniques through the literature 
review, an overall design strategy for the program was initiated. An initial prototype of 
the various screens was developed and presented to various potential users for feedback. 
Several iterations of this process resulted in a final prototype that successfully met 
general interface design principles. Implementation consisted of coding and testing each 
screen module before the final integration and testing for the entire program. 
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D. SCOPE AND DIRECTION 


The main focus of this thesis is presenting the design considerations for developing 
a GUI-based program. Examples and techniques unique to this environment will be 
presented and explored. Where appropriate, character-based versus GUI-based interface 
design considerations will be contrasted. 

The second chapter w ill open with a broad over\iew of general interface design 
principles. Five main categories of inte.'faces will be discussed and compared with 
particular attention focused on the graphical user interface. The third chapter will 
discuss the actual design and implementation of a Bilateral Ni^S. Design features and 
considerations for the individual modules of the Bilateral NSS will be presented. The 
final chapter will summarize the findings and make recommendations for future research. 

The framework and model for the Bilateral NSS described in this thesis is 
reproduced in Appendix A. Appendix B excerpts the end user manual guidelines set 
forth in DOD standard 7935A. The Bilateral NSS user's manual is provided in 
Appendix C. 


4 







II. INTERFACE DESIGN OF NEGOTIATION SUPPORT SYSTEMS 


A. GENERAL INTERFACE DESIGN PRINCIPLES ANT) ISSUES 

Successful computer programs begin with an intelligently designed user interface. 
Without a good interface there is little incentive for the user to continue to use your 
program. "... if the computer industry is successfully to extend its user base it must 
urgently attend to developing user-friendly interfaces” (Coombs, 1981). It is therefore 
incumbent upon the program designer to become thoroughly familiar with two important 
aspects of good software design; understanding the needs of the intended users of the 
program and the generally accepted guidelines of proper interface design. 

This chapter begins with a review of interface design techniques. The strengths 
and weaknesses of the various designs will be examined as well as the rationale for 
choosing the graphical user interface over other possible alternatives. The last part of 
this chapter will deal with the actual design considerations involved in the programming 
of the Bilateral NSS. 

1. Types of Interfaces 

In his book on designing the user interface, Shneiderman identifies five 
categories of user interfaces (Shneiderman, 1987). They are; 

• Menu Selection - In this method the user is presented with a list of items and must 
choose one by highlighting his choice or pressing the appropriate key. This style 
is appropriate for novice and intermediate users. It is easy to learn, provides for 
structured decision making and supports error handling. Disadvantages include the 


5 





danger of creating too many layers of menus and slowing the speed of use for 
frequent users of the program. 

• Form Fill-in - This method displays a group of fields for user fill-in. The fields 
are normally navigated by use of the cursor or tab keys. This style is appropriate 
when data entry is the main form of interaction. It simplifies data entry , requires 
modest training and permits the use of form management tools. 

• Command Language - This method relies on the user learning a group of 
commands that are often complex and cryptic in nature. This style is appropriate 
for experts and frequent users of the program. It allows the user to quickly initiate 
commands with short and highly complicated syntax. Disadvantages include p>oor 
error handling and substantial user training. 

• Natural Language - This method allows users to enter words or phrases in a natural 
la guage format. Its chief advantage is that it can relieve the user from having to 
learn an obscure command syntax. Disadvantages include the requirement for 
frequent "clarification dialogs" and the possibility of being slower and more 
cumbersome. 

• Direct Manipulation (Graphical User Interface) - This method involves the visual 
representation of objects and actions of interest to the user. The user is allowed 
to select from a visible set of objects and act upon those objects by means of 
various cursor motion devices such as mice, trackballs and keyboards. It is 
relatively easy to learn ind retain for both novices and experts. Disadvantages 
normally include more difficulty in programming and the requirement for additional 
pointing devices and higher quality displays. 


As can be seen from the above list, there are a variety of interface design 
methods at the disposal of the computer programmer. Choice of a method depends on 
the complexity of the program and the experience level of the programmer. Each one 
requires the programmer to correctly analyze both the user’s requirements and the 
necessary functionality of the program. In a Danish textbook on interface design 
(Nielson, 1989), five guidelines for the process of user interface design were presented. 
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They are: 


• Know the user 

• Involve users during the design 

• Coordinate the total user interface 

• Empirical measurements 

• Iterative design to remove usability problems 

As can be seen in the above guidelines, the user is a key element in almost 
all aspects of interface design. The programmer must avail himself of every opportunity 
to get user input and feedback during all stages of program development. The final 
guideline is especially critical. Even with user involvement during the early stages of 
system design, until the user is able to interact with your program, the success of your 
design is highly tentative at best. When practicable, a design philosophy based on rapid 
prototyping will yield more success than the ''waterfall" method of system design (Page- 
Jones, 1988). 

2. Graphical User Interface 

Until the unveiling of the Apple Macintosh in 1984, almost all interface 
design followed the general guidelines enumerated in the first four of Shneiderman's 
methods. Although still used for certain applications, the direct manipulation or 
graphical user interface has supplanted the earlier design methods as today’s design of 
choice. Indeed, today’s software applications need graphical user interfaces to sell 
(Zachary, 1990). 
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Currently, there are a wide variety of GUIs running on almost all available 
hardware/software platforms. Some examples are: 

• Microsoft Windows 3.0 on IBM compatible systems 

• GeoWorks Ensemble on IBM compatible systems 

• IBM Presentation Manager for OS/2 

• Motif for Unix-based systems 

• NextStep for the Next computer 

In a tutorial on graphical interface design (Marcus. 1990), the author stresses 
the importance of visually communicating a program's data and functions. Proper use 
of graphic design principles and an effective use of "visible language" contributes to 
improved visual communication. The author defines visible language as "...all the 
graphical techniques used to communicate the message or content." Some aspects of 
visible language are: 

• Layout: formats, proportions and 2-D and 3-D organization 

• Typography: selection of typefaces and typesetting 

• Color and texture: color, texture and light that convey pictorial reality 

• Imagery: signs, icons and symbols 

• Animation: a dynamic or kinetic display that is especially important for video 
related imagery 

• Sequencing: the overall approach to visual storytelling 

• Sound: abstract, vocal,concrete or musical cues 
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• Visual Identity: the additional, unique rules that lend overall consistency to a user 
interface 

Careful manipulation of this visible language and judicious adherence to the 
following set of design principles will help to ensure a successful well thought out 
graphical design. The three principles and amplifying concepts within each principle are 
detailed belou. 

a. Principles of Graphic Design 

(I I Organize 

Provide the user with a clear and consistent conceptual structure. 
Four important concepts associated with this principle arc: 

• Consistency - observe the same conventions and rules for all elements of the GUI. 

• Screen layout - standardize the screen layout and group related items. 

• Relationships - link related elements and disassociate unrelated elements. 

• Navigability - provide an initial focus for the user; direct attention to important 
items; and assist in navigation throughout the material. 

(2) Economize 

Maximize the effectiveness of a minimal set of cues. Four concepts 
associated with this principle are: 

• Simplicity - include only those elements that are essential for communication. 

• Clarity - design all components so that their meaning is not ambiguous. 
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• Distinctiveness - distinguish important properties of essential elements. 

• Emphasis - make the most important elements salient, de-emphasize non-critical 
elements and minimize clutter so that important information is not hidden. 


(3) Communicate 

Match the presentation to the capabilities of the user. Six concepts 
associated with this principle are; 


• Legibility - design characters, symbols and graphic elements to be easily noticeable 
and distinguishable. 

• Readability - make the display easy to interpret as well as inviting and attractive. 

• Typography - use a small number of typiefaces. Generally, you should use a 
maximum of three typefaces in a maximum of three point sizes. 

• Symbolism - carefully design icons, charts, maps and other imagery to properly 
convey the desired contents. 

• Multiple Views - provide multiple perspectives on the display of complex structures 
and processes. 

• Color/Texture - use a consistent color code for screen displays and a maximum of 
five plus or minus two colors in each display. 

b. Hardware Elements 

Common to all GUIs are several hardware elements. They are: 

• High resolution graphics displays 

• Pointing devices such as mice, trackballs and pens 

• Keyboards 
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c. Software Elements 


In addition to common pieces of hardware, there are software elements 
common to most GUIs. They are: 

• Windows 

• Pull-down menus 

• Dialog boxes 

• Icons 

• Buttons and scroll bars 

• Cursors 


Careful examination of the Microsoft Window s 3.0 interface will reveal 
a general adherence to the principles and elements enumerated above. To accomplish 
this, the Microsoft Windows 3.0 system was designed using GUI standards detailed in 
an IBM document called the Common User Access Advanced Interface Design Guide 
(IBM, 1989). Common User Access (CUA) is a portion of IBM's System Application 
Architecture (SAA) that defines an overall set of interface standards. Conformance to 
the CUA ensures consistency of the interface across platforms as well as software 
applications on a single platform. 
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B. GUI DESIGN FOR NEGOTIATION SUPPORT SYSTEMS 


The GUI guidelines presented in the previous section are in principle applicable to 
all software interfaces. For NSS software, there are, however, some additional design 
concepts that should be considered. 

Bui (1987) argues that the following topics should be tal;en into consideration when 
designing for a group decision environment 


First, a Group Decision Support System (GDSS) should provide both formal and 
informal man-machine-man interfaces to enhance information exchange within 
group members. Second, the GDSS should be designed in such a way that (i) it 
becomes favorable media for solving group problems, and (ii) it ensures that 
decision makers do not waste unnecessary resources in interpersonal exchange at 
the expense of a thorough discussion of the object of the group problem. 

... a user interface of a DSS should (i) be transparent and consistent to make the 
system easy to learn, use and remember; (ii) be suitable for both novice and expert 
use; (iii) let the user have control of the system and feel competent in task 
performance; (iv) promote effective usage and better decision-making; (v) and be 
efficient in the use of system resources (Stohr and White, 1982; Shneiderman, 
1986). Although these design principles should prevail in building GDSS, 
importance should be given more to the concept of ease-of-use and transparency. 

... DSS users are often decision makers who deal with strategic and ill-structured 
problems. It is reasonable to expect that (i) the frequency of GDSS use is low and, 
(ii) familiarity with computers is insignificant to none. Under such a decision 
environment, a comprehensive, structured and controlled interface, such as 
sequences of hierarchical menus or carefully designed queries, seems to be most 
appropriate in order to satisfy the five design principles mentioned above. 
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In addition to Bui's arguments, Lim and Benbasat (1991) propose a conceptual 
framework for designing software interfaces for group decision support systems. They 
suggest four dimensions that need to be examined in group interface design; 


• Concurrency - this dimension describes the type of collaboration between members 
of a work group. The tempura! aspect of this dimension concerns itself w'ith 
whether the collaboration is synchronous or asynchronous. The spatial aspect 
describes whether the collaborators are collocated or dispersed. 

• Content - this dimension describes the type of message passed between members 
of a group. There are two categories - task-oriented or social-emotional. 
Computer-mediated communication tends to be richer in task-oriented than social- 
emotional messages. 

• Path - this dimension describes the type of communication path. Some of these 
paths may be collaborator - collaborator, collaborator - works , rion - 
collaborator, collaborator - display, etc. 

• Channel - this dimension describes the characteristics of the medium through which 
communication occurs. Two issues are discussed - teclmoloyiy support and mode. 
The modes by which collaborators communicate may be classified by the degree 
of social presence conveyed. In a computer-mediated context, the textual and 
graphical/symbolic modes at the low end of the social presence spectrum are 
predominant. 


The above mentioned design considerations are not totally unique concepts. 
Rather, they build upon the general design techniques enumerated in the previous section. 
They attempt to address some of the special characteristics inherent in a computer- 
mediated environment. When applied to the GUI design of the Bilateral NSS, they give 
the designer additional insight into the type of person that uses a NSS program and some 
of the environmental issues he may be exposed to. 
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The next section will take the design ideas presented in this chapter and attempt to 
apply them to the design of a Bilateral NSS. Although certain aspects of the above 
discussion are not applicable to the design of this particular Bilateral NSS, the general 
guiding principles and special considerations of this project will be explained. 
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III. DESIGN AND IMPLEMENTATION OF A BILATERAL NSS 


This section presents the philosophy used in designing the Bilateral NSS. The first 
part of this section discusses the GUI specifications for the Bilateral NSS. The second 
section discusses the design considerations for the program as a whole. The last part 
breaks down the Bilateral NSS program into its lanctional pans and discusses the 
programming and design considerations used. 

A. Gl 1 SPECIFICATIONS 

Based on the previous discussion of general graphic design principles and the 
framework proposed by Lim and Benbasat. the following specifications have been 
determined for the GUI interface; 

1. Concurrency 

a. Temporal 

The system should be distributed in time. Both negotiating parties can 
access and use the Bilateral NSS at different points in time. 

b. Spatial 

The system should be distributed in space. Both negotiating parties can 
either use the Bilateral NSS in face-to-face mode or at two different physical locations. 
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2. Content 


a. Task-oriented 

The system should use a formal and comprehensive multiple attribute 
utility theor>' to define negotiators' tasks. 

b. Social-emotional 
N/A 

3. Path 

As a minimum, the Bilateral NSS should support the following 
communication paths; 

• collaborator - collaborator 

• collaborator - workstation - collaborator 

• collaborator - display 

4. Channel 

The main thrust of the Bilateral NSS is its application of multiple attribute 
utility theory to the negotiation process. Therefore, the mode of operation can be at the 
low end of the social presence spectrum. Ideally then, the predominant sub-mode should 
be graphical/symbolic if we are to exploit the advantages of the graphical user interface. 

Particular aspects of designing the visual representation presented to the user are 
discussed in the next section. 
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B. METHODOLOGY 


The first step taken in designing this program was to look at the original program 
as it w'as implemented in the C language (Gilley. 1991). The screen layouts and menu 
structure were penciled out and the general flow between them were analyzed. After 
initially trying to design the program using the old system structure, it became apparent 
that trying to directly conven it over to a graphical interface would not be successful. 
Although the menu-driven structure was adequate for the character-based interface that 
it was originally written for. a direct conversion would not in any way use the graphical 
user interface to its fullest advantage. 

The second step was to come up with an overall flowchart of the program. All the 
information needed to be input by the user and all the information needed to be presented 
to the user was vs ruten dowtr. This data was then broken down into logical groupings. 
The next jtep was to figure out how best to present this data to the user in a clear and 
logical manner. After designing the initial prototype that included the general screen 
layouts and the interaction between them, it was presented to several potential users for 
feedback. Several iterations of this cycle eventually produced the final working version. 

The initial design layout was developed by adhering as much as possible to the 
guidelines outlined in the Common User Access guide. This document details a standard 
set of guidelines to follow when designing graphical interfaces for Windows and OS/2 
programs. Standard menu bar configurations, screen layouts and minimum screen 
controls are some of the many design considerations presented. Some of the screen 
design issues that were standardized across the entire program are (See Figure 1): 
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• Button position - all buttons are located on the bottom righthand side of the screen. 
If the width of the screen is sufficiently small, the buttons are equally spaced 
across the entire bottom. The Help button is always the rightmost button in the 
row. 

• Button types - almost all screens have an OK and Cancel button. If both are 
available the OK button is always on the left. 

• Colors - a similar color scheme is used for all screens. A limited number of colors 
were used when groups of data needed to be highlighted. 

• Help system - a Help butuni is available on all screens. This button "ovides 
context-sensitive help for the current operation. 


Party A Priorities 


Select Method for Rankirrg Issues 


<¥' Equal Weighting 
O Direct Prioritization 
O Pairwise Comparison 


OK 


Cancel 


Figure 1 

Sample Program Screen 


C. INDIVIDUAL SCREEN DESIGN 

The following sections discuss the design considerations used in developing the 
screen layouts for the various portions of the Bilateral NSS program. 

1, Main Bilateral NSS Screen 

Figure 2 shows the opening screen the user sees when starting the Bilateral 
NSS program. Window design components normally available on all Windows 3.0 
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application programs were used. These include the upper left Control Menu button, the 
upper righthand minimize and maximize buttons and the main Action Bar. The 
arrangement of the two Action Bar items are in compliance with the CUA guidelines. 
The background graphic of the shaking hands was included to visually convey the intent 
of the program. 



Figure 2 

Bilateral NSS Opening Screen 
2. File Menu Screens 

The four screens that follow are associated with the commands listed under 
the File Menu on the Action Bar. 

a. Start .S'ew Session Screen 

Figure 3 shows the screen displayed when the user selects the Starr New 
Session command under the File Menu. This command is selected to begin a new 
negotiation session. The user is prompted to enter the filename he wishes to store the 
data under. The standard set of control buttons are located along the bottom of the 
screen for consistency with all other screens. A Cancel button is provided to allow the 
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user to cancel the command if he decides to. As always, a Help button (denoted by the 
? symbol) is the rightmost button. 



b. Open Prior Session Screen 

Figure 4 sho\s s the screen displayed when the user selects the Open Prior 
Session command under the File Menu. The standard complement of control buttons is 
again located on the bottom of the screen in the same relative position as all other 
screens. This particular orientation of the file, directory and drive list boxes is the new 
standard for all applications written for Windows 3.0. This particular screen will look 
familiar to all users who run other Windows applications. 
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Open Prior Session 
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♦ 
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c:\ftindowt\vbatic\n | 

1 

or 


Cancel 

HI 


Figure 4 

Open Prior Session Screen 


c. Save Current Session and Save Current Session As Screens 

Figures 5 and 6 shuw the screens the user sees when selecting the Save 
Current Session and Save Current Session As commands, respectively. 


Save Session 

Save data changes foi 
current session? 

Filename: Testlile 


Save 


Cancel 



Figure 5 

Save Current Session Screen 


The button layouts are consistent with other program screens. The 
screen designs are very similar since they are used for the same basic purpose. For the 
Save Current Session As command, the user is provided with a text box to enter any eight 
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character filename. If non-allowable characters are entered, a message box indicating 
the error is displayed. 


Save Session As 


Enter File Name: 
T eslfile 


Save 


Cancel 


■> 

• 


Figure 6 

Save Current Session As 


3. Help Menu Screens 

The two screens that follow are associated with the commands that are listed 
under the Help Menu on the Action Bar. 

a. Index Screen 

Figure 7 shows the screen displayed when the user selects the Index 
command located under the Help Menu. This screen is the only one that was not 
designed using the same control layout considerations as the other screens. The use of 
OK and Cancel buttons was not appropriate since their meaning to the user would not 
have been clear in this situation. To get the user’s attention, a set of program topics in 
the center of the screen are grouped together. The labeling of the Get Help and Quit 
buttons was used to clearly convey their intent if pressed. 
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Figure 7 

Help Index Screen 


b. About... Screen 

Figure 8 shows the screen displayed when the user selects the About... 
command located under the Help Menu. It is common practice to include this command 
under the Help Menu to indicate the program's current version, authors and any other 
information deemed appropriate. 
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4. Main Selection Menu Screen 

Figure 9 shows the screen displayed when the user starts the program by 
either opening a prior session or by starting a new session. The ordering of the menu 
items w'as chosen so that the first item a user would most likely go to was displayed at 
the top. Additionally, the default radio button is also the first item. The double column 
format was chosen as the most appropriate design to both limit redundancy and provide 
a symmetrical display. Button layouts are standard and the Quii button was used instead 
of the Cancel button since it would convey a clearer meaning to the action of leaving the 
Main Selection Menu. 
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Figure 9 

Main Selection Menu Screen 


5. Issue Parameters Screen 


Figure 10 shows the screen displayed when the user selects the Issue 
Parameters item from the Main Selection Menu. The lines were designed so that the 
user’s cursor is automatically mo\ed to the next available text box when he presses the 
Enter key. This helps to speed up user data entry. To enter an initial starting offer the 
user has two choices. He can directly enter the value in the text box provided or use the 
scroll bar located beside each text box. Two additional control buttons. Add New Issue 
and Delete Issue, are provided to give the user a positive means of initiating those 
actions. 
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Figure 10 

Issue Parameters Screen 


6. Name or Party Screen 

Figure 11 shows the screen displayed when the user selects the Name or 
Parry item in the Main Selection Menu. This screen uses the standard button layout with 
two additional text boxes. If the user exceeds the 15-character limit for either text box, 
a message to that effect wilt be displayed. 


** Parly A Data Update Screen 



Negotiatoi Name 

Ambassador Hall 



Negotiatof Parly 

United Stales 



OK 1 

Carurel 1 

..-.-. '1 


Figure II 

Name or Party Data Screen 
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7. Issue Priorities Selection Screen 

Figure 12 shows the screen displayed when the user selects the Issue 
Priorities item from the Main Selection Menu. The screen is a standard option button 
screen with the normal three button layout. 


_ Party A Priorities 

Select Method for Ranking Issues 


^ Equal Weighting 
O Direct Prioritization 
O Pairwise Comparison 


OK 


Cancel 


'> 





Figure 12 

Issue Priorities Screen 


8. Issue Priorities (Direct Entry) Screen 

Figure 13 shows the screen displayed when the user selects the Direa 
Prioritization option from the Issue Priorities Selection Menu. Values can be entered in 
the Weight column by direct entry in the text box or by using the scroll bars located 
beside each text box. The standard three button layout is used in this screen also. 
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Figure 13 

Issue Priorities (Direct Entry) Screen 
9. Utility Values Screen 

Figure 14 shows the screen displayed when the user selects the Uriliry Values 
item from the Main Selection Menu. The main design consideration in setting up this 
screen was how to make user entry of utility data as simple and intuitive as possible. To 
provide a graphical look to the display, seven columns of 11 radio buttons were used. 
The user simply has to click the desired button in each column to make his preference. 
The completed display presents the data in an x-y graph fashion. Since there are seven 
utility values associated with each issue a separate box was provided to allow the user 
to select which issue he would enter data for. The remaining buttons are in a standard 
layout. 
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10. Negotiation Results Screen 

Figure 15 shows the screen displayed when the user selects the Negotiation 
Results item from the Main Selection Menu. Based upon the type of data presented, the 
tabular format was the most logical choice. The column total text boxes were separated 
from the rest of the data to give the user a clearer presentation. A distinctly different 
color was chosen for the Scratch Pad column that allows user modification to better 
indicate its unique nature. Descriptive names were chosen for the screen buttons to 
clearly indicate their purpose. 
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11. Display Graphs Screen 

Figure 16 shows the screen displayed when the user selects the Display- 
Graphs button from the Negotiation Results screen. To augment the tabular data 
presented in the Negotiation Results screen, a graphical representation of the data was 
provided. The graph portion of the screen uses a three color layout to clearly present 
the data. The display grid is re-scaled for each issue to provide the maximum usable 
display area for each set of data. A standard option button selection scheme was chosen 
to select the desired issue for display. Two option buttons are also included to allow the 
user to toggle between weighted and unweighted data. 
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Figure 16 

Display Graphs Screen 


31 













IV. SUMMARY AND SUGGESTIONS FOR FLTURE RESEARCH 


A. SUMMARY 

The goal of designing a graphical user interface for the Bilateral NSS was achieved. 
The GUI design followed the commonly accepted graphic design principles enumerated 
in this thesis. Additionally, the CUA standards outlined in IBM's System Application 
Architecture were followed to the maximum extent possible. It is believ ed that the GUI- 
based version of the Bilateral NSS will receive a favorable response in comparison to the 
original character-based program. 

B. SUGGESTIONS FOR R TIRE RESEARCH 

Several follow on studies are suggested as a result of this thesis. First, a study 
could be conducted to measure user preference between the GUI-based and character- 
based programs. Since the task sets of the programs are identical, a valid comparison 
could be made. Second, additional capabilities could be added to the original program 
to further enhance the negotiation process. This might include dynamic updating of 
graphs and tables with multiple views of the information on the screen. Third, the 
program could be integrated into a broader Group Decision Support System. The 
Bilateral NSS could be added as a module to such a system. 
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Abstract 

This paper presents a bilateral Negotiation 
Support System (N’SS) based on a multi-attribute 
uiiUiy model that adapts a fuzzy set methodology 
in determining user's preference functions The 
system can concurrently handle negotiations that 
span across multiple mediating issues in a 
man/ter that increases the joint utilit}' of both 
po’-tics The N’SS is expected to impart a more 
interactive and realistic approach to capturing 
uncertainties while developing the utilin 
functions using the standard approach. The 
potentiality of the proposed NSS lies in its ability 
to allow negotiators to evaluate potential treaties 
quickly, explore alternate arrangements that 
reveal to be more advantageous to both parties 
than those which arc arrived at intuitively. 


1. Introduction 

Negotiations have always been an 
integral part of business, organizational 
management, and international affairs. With ever 
increasing competitiveness, negotiations require 
greater sophistication an'^ faster recnlution 


Today the information and knowledge of the 
parties involved arc more technologically 
complex, making it more difficult to crisply 
define agreements leading to a compromise. 
Oftentimes, each party to the negotiation knows 
conceptual!}, the multiple issues of the problem 
in fairly good detail, but this is not sufficient to 
define each other’s preference/utility functioas in 
a deterministic an interactive fashion. Current 
systems, however, can handle only deterministic 
inputs. In reality, utility functions are not 
deterministic and negotiators are willing to budge 
their positioas in small variants during actual 
negotiations. 

This paper proposes an extension to a 
Pareto-optimum model that maximizes the 
utilities of the two parties using the fuzzy set 
concept to capture the negotiators’ preferences 
function. The paper is organized as follows. 
Section 2 addresses the problems in bilateral 
negotiations Design issues for building bilateral 
Negotiation Support Systems (NSS) arc 
discussed in section 3. Section 4 lays down the 
basic steps of an interactive multi-attribute model 
for negotiation involving multiple treaties 
between two parties. In section 5, we explain 
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i!ic use of fu77,y sets in formulating negotiators’ 
preferences as an improved means for the ulilits 
modeling. Section 6 illustrates the model using 
an example. 


2. Background 

Traditionally, bilateral negotiation is 
often viewed as a distributive bargaining in dial 
it operates on the notion of a ''fixed pie" which 
must he shared between the two parties. Bodi 
protagonists seek to maximi7e their own goals 
without concern for the other. Research has 
shown that distributive bargaining or die wiri- 
lose approach leads to capita!i7.ing on power 
differentials, escalating hostilities, suboptimal 
agreements, and ultimately, an uncooperative 
relationship for future negodations (e.g., Lcwicki 
and Litterer, 1985). 

An alternative approach is die integrative 
bargaining or win-win method. This seeks to 
re<:olvc conflict with a set of procedures that 
pemiit both sides to maximi7C their objectives. 
Inicgrativc bargaining generates solutions that 
yield high joint benefits, thus contributing to a 
more positive relationship (Tisher and Ury , 1981; 
Pruitt, 1981). 

Real life negotiations are, however, 
characterized by a mixture of distributive and 
integrative elements. This phenomenon is 
known as mixed-motive paradigm. Hence, it is 
important to identify interest differentials quickly 
to help negotiators diagnose and reduce conflicts, 
thus moving towards integrative bargaining. 

There are a number of problems 
associated with negotiation. In a bilateral 
negotiation, the protagonists assume that their 
interests are always in conflict with each other. 
Bazerman (1983) argues that this entrenched 
assumption inhibits the creativity and problem¬ 
solving necessary for the development of 
integrative solutions. Empirical studies have also 


found that negotiators may not always be 
cognizant of their judgment criteria. Further, 
they may not be able to assess correctly the view 
of their counterparts (KJeinmuntz, 1990). Social 
and emotional factors have also been found to 
affect objectivity and rationality in negotiations. 
Kessler (1978) suggests that successful conflict 
resolution depends on successful use of 
techniques that could handle .socio-emotional and 
cognitive bias issues inherent in conflict 
situations. As discussed later in this paper, we 
argue that by using a formal and comprehensive 
methodology for negotiations, the parties 
involved - possibly the arbitrator as well - 
could provide a structure for systematic 
information exchange and f'culd lessen the 
personal biases of both parties. A computerized 
system that implements this methodology will be 
very useful in negotiations. 


3. A Framework for Bilateral NSS 

Figure 1 depicts a framew-ork for 
designing a NSS for bilateral negotiation based 
on the Type VI of GDSS defined by Bui (1987). 
Each party can have his/her own DSS that 
contains models customized to his/her needs that 
individually describe the issues (DSSl and 
DSS2) The Negotiation Module allow'S the 
negotiators to engage in a joint and opxm 
modeling effort. In practice, technical experts 
and advisors usually supply the bulk of 
information to the negotiators either before or 
during the negotiation process. Even if such 
information is accurate and complete, there is no 
reason why the negotiators themselves could not 
■exercise their freedom of choice at the time of 
negotiation through joint concession, and 
experimentation of simpler models of their owo. 
Nyhart and Samarasan (1987) contend that this 
can help the negotiators appreciate better the 
strengths and weaknesses of the other party’s 
position and arguments. A joint and open 
modeling effort may be to the advantage of both 
parties. 
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Figure 1. A Framework for Bilateral NSS 


The NSS should provide a model-based 
interactive facilitation process that offers a 
comprehensive framework to allow the parties to 
concentrate on joint problem-solving rather than 
on convoluted arguments The objectives of 
using a NSS arc listed below : 

1. Establish a consensual database as a 
foundation for negotiation, 

2. Evaluate the impact of perceived 
uncertainty, 

3. Provide communication links for 
bargaining and di,scussion, 

4. Suggest restructuring for non-cooperative 
issues, and 

5. Help search for agreements through 
Pareto-oplimization. 

Computer support can be used to assist 
the negotiators in interactive information 
elicitation and process them in an orderly 
manner. It can al.so update data as inputs are 
entered, and present the results of analysis both 
tabularly and pictorially. It should also act as a 
tool to let negotiators know that their 
compromises or concessions can be implemented 


and will produce the desired and agreed-upon 
results. 


4. An Interactive Procedure 
for Bilateral Negotiation 

This section focuses on the negotiation 
module described in Figure 1. It describes a 
formal and comprehensive model for joint 
problem solving. The purpose of the model is to 
focus on asymmetries of interests between the 
two parties so that the terms of the final treaty 
are better for both (Barclay and Peterson, 1978). 
The whole algorithm is based on the Pareto 
principle applied to a bilateral negotiation 
situation. A treaty is Pareto optimum when it is 
no longer possible to increase the utility of one 
party without decreasing the utility of the other. 
A good treaty is one that yields to each party 
those issues which are more important to 
him/her. Thus the two parties should try to push 
the negotiation toward the Pareto optimum by 
capitalizing on asymmetries of interest, and 
sometimes by redefining the situation to reveal 
more asymmetries. 
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The essence of the procedure is described below: 

Step / Identify the major treaties which the two 
panics would like to sign. For example, say the 
U.S. and a host country are negotiating on the 
extension of a military base treaty and 
establishing a bilateral trade treaty. 

Step 2. For each of the treaties being considered, 
identify a common .set of major issues about 
which the two parties disagree. The initial 
positions of the parties on each of the issues 
should be stated. Assume that for the military 
base treaty, the negotiators have identified the 
issues important to their nations as duration of 
the use of the military base by the U.S.. civil 
jurisdiction of the host country over the military 
personnel, and U.S. economic compensation. 

Step 3 Each party assigns a relative weight to 
each of Uie issues. It is important to understand 
the meaning of die relative weight in a bilateral 
negotiation context. Tlie weights represent the 
relative importance of the difference between the 
panics' position. For example, if the U.S gives 
a weight of 20 points to duration and 10 to 
economic compensation, the U.S. docs not 
consider the first issue to be two times as 
important as the second issue. Rather, the 20/10 
ratio implies that the U.S. considers the change 
from the host position to the U.S. position on the 
economic compensation issue to be twice as 
important as the change from the host position to 
the U.S. position on the duration issue. A.ssume 
that the weights for the three issues arc 
(50.30.20) and (65,5,30) for the U.S. and the 
host country respectively. 

Siep 4. Define the range of values for all the 
issues as identified by both parties. For 
example, the U.S. may not be willing to sign a 
treaty unless it spans a minimum of 10 years, 
whereas the host country may want to restrict the 
duration to 5 years. It can be inferred that the 
negotiation will encompass the period between 5- 
10 years. A utility curve can be drawn for 
different values between the 5-10 year range. 


Figure 2 shows the utility curves for duration, 
jurisdiction and compensation for the two 
countries. Note that the.se curves are unweighted 
in that they do not take into consideration the 
relative weights on the issues described in step 3. 

Step 5. For each party, assign relative weights to 
utility curves. This is done by taking the 
product of the utility values (vertical axes of the 
graphs in Figure 2) and the respective relative 
weights of the issues. 

Step 6 For each issue, compute the joint utility 
curve by adding the utility functions of the two 
countries. 

Step 7. Detemiine the total utility for each nation 
across all the issues. Using the maximum utility 
principle, the value of an issue is the highest 
point on the joint utility curve. For the first 
iteration, llic data shown in Figure 2 yield to a 
total utility of 65 for the host country and 30 for 
the U.S. 

As the outcomes suggest, it is imperative 
to look for a better distribution of utility points. 
For this situation, as shown in Figure 3, the 
proposed NSS would check for non-cooperalive 
issues and calls for restructuring A cooperative 
situation is one in which the highest value of the 
joint utility curve is higher than the individual 
maximum utility values of both parties. 
Conversely, a non-cooperative situation is one in 
which the highest value of the joint utility curve 
corresponds to the highest for only one of the 
parties, leading to the standard zero-sum game 
scenario. In this circumstance, it is 
recommended to split the single non-cooperative 
issue into sub.sets of more asymmetrical issues 
for further search for higher Pareto optima. Note 
that there exists other aggregation to determine 
the total utility for both parties, e.g., mid-point 
analysis, equal utilities, etc. 

The model as described in this section 
requires perfect information and is very sensitive 
to perturbations (e.g., falsification of weights or 
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Figure 2. An Example of Multi-Attribute Utility Function 
(adapted from 11)) 
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Figure 3. An Interactive Procedure for Bilateral Negotiation 
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unilateral disclosure of true preferences i For the 
safe of space, these issues arc not discussed 
further, although they could be resolved by a 
careful and ordered preparation of the negotiation 
process. 

5. Fuzziness in Preference Formulation 

Experience has shown that it is difficult 
for the negotiators to define precisely their utility 
functions for the issues (Step Negotiators 
might not understand the precise meaning of the 
utility scale (eg., O-KKf in the example). Yet. 
they arc forced to provide ensp inputs for the 
utilities Human quantification is fuzzy at best, 
and a narrow range of acceptable values might 
exist around the crisp utility value suggested by 
the negotiator. Zimmermann (1987) asserts that 
under such circumstances, using fuzzy sets can 
capture tlic uncertainty or vagueness of the 
negotiators better. 

A fuzzy set contains one or more pairs 
of numbers. The first of each pair represents a 
dc'main element. In this negotiation context, the 
domain element is the utility values [O.IOO] with 
respect to the issue range. The second element 
in the pair is the degree of membership of lliat 
element in die fuzzy set ranging from 10,1] 
(Norwich & Turksen, 1984). For example, the 
fuzzy set for a scale response 80 (on a 0-100 
utility scale) would contain 80 with certainty 
(i.c., membership valuc=l) and the other 
proximate values (e g.. 70, 75. 85, 90) with 
lesser degrees of membership (e.g., 0.4, 0.8. 0.9, 
0.75). 

Through the u.se of fuzzy sets for each 
scale response to create the utility function, 
vagueness or complexity in the input information 
can be captured. Instead of eliciting the utilities 
of the negotiators with regard to the issues 
directly by a.sking them to provide a cri.sp 
definition of their utility curves, the fuzzy sets 
approach attempts to seize the uncertainty from 
the negotiators inputs and reconstruct their utility 


functions. The utility value can be reconstructed 
by using the weighted sum. 

6. An Example of Formulating 
Fuzzy Preference 

In the NSS using fuzzy set technique, 
the preference elicitation is achieved as follows. 
For a specific value of a given issue, die user is 
prompted for a utility value. The utility value is 
assigned to be the domain element associated 
with a membership value of 1. If the user 
indicates that there exists other domain elements 
having positive membership values, the system 
prompts the user for membership values for 
proximate utilities (for example, values ranging 
10 points around the initial domain value 
whenever possible). The set of utilities widi 
their memberships for a given issue value is 
referred to as a fuzzy function. 

Let us say after elicitation, the fuzzy 
function for a treaty of 10 year duration for the 
U.S. looks as follows: f(juration^’^ = 

((70.0.4). (75,0.8), (80,1), (85,0.9), (90,0,75)]. 
We arrive at a single utility value for duration of 
10 using die weighting scheme mentioned 
earlier. (70*0,4 + 75*0.8 + 80*1 + 85*0.9 + 
90*0.75) / (0,4 + 0.8 -r 1 -I- 0.9 + 0.75) = 81. 

The procedure is then rci:)eatcd for other 
possible values of the duration issue. The 
resulting set of utility points are then used to 
specify the utility function. The utility fiinctioas 
of other issues can also be done in a similar 
manner. 


7. Summary 

To use a formal muld-attribute 
negotiation model, negotiators are supposed to 
provide consistent and stable preference 
information. This information should not 
contradict with previous judgments. The 
interactive procedure proposed in this paper 
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seeks to allow the negotiators to strengthen their 
preference structure. This can be achieved 
through an interactive exploration of the fu77\ 
sets. We expect that true preferences will nnally 
emerge from the learning process made pos.vil w 
by the system. The algorithm discussed in this 
paper is a specific treatment of preference 
information. Funher research is required to 
explore better elicitation of preference 
information. 
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APPENDIX B 


DOD STANDARD 7935A END USER MANTAL GUffiELINES 

The End User Manual is a vital reference source for the functional user of an 
application. It must contain an overview of the application package as w'ell as an 
explanation of all of the instructions, formats and procedures by which the functional 
users can utilize the system. 

1. OBJECTIVES 

The manual should, as a minimum, meet the following objectives; 

1.1 Acquaint new users of the application package with its features and purposes. 

1.2 Show new users how to perform tasks utilizing the application package. 

a. Pros ide a quick, easy reference for all users. 

b. Describe the menu format of the application package to help the user to 
navigate through the system. 

c. Help the user determine which online screens relate to forms used 
on-the-job for the business process. 

d. Enable the user to use all entry'update/display screens related to tasks 
performed on-the-job. 

2. MANUAL ORGANIZATION 

The manual should contain major topics, such as: 

2.1 General Information - The purpose of the End User Manual and of the system, 
reference materials, terms and abbreviations, and security. 

2.2 An Overview of the System - The hardware and software required, 
contingencies and alternate modes of operation, and reporting 
problems. 
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2.3 Getting Started - How to gain access to the system, logon requirements, 
other user authorization requirements, special commands, and function keys. 

2.4 Business Processes - How to use all transactions required in the performance 
of the tasks of the business process. How to find and retrieve information in 
the Database and/or manual files. Data backup, error messages, recovery from 
errors and malfunctions, and sample reports (hard copy and online). 

The Department of Defence (DoD) provides guidelines for the development of 
documentation. As a branch of DoD, and because of the nature of the Information 
Engineering program at the U.S. Army Corps of Engineers (USAGE), Application 
Development Projects should adhere to this documentation standard know n as DoD-STD- 
7935 A. 

DoD-STD-7935A lists two types of User Manuals that may be produced during the 
life cycle of an Automated Information System (AIS); 

• Users Manual 

• End User Manual 

The Users Manual is a high level, nontechnical overs’iew of a specific AIS 
application and its use in the business process. Refer to the Standard for further 
description. 

The End User Manual provides detailed information necessary to enable the 
functional user to effectively use the system. The emphasis in this app>endix is on the 
End User Manual. The following is the formal structure specified in DoD-STD-7935A: 
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DoD-STD-7935A 
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3. DEVELOPING SECTIONS OF THE ENT) L'SER MANUAL 


Like all dcKumentation components of DoD-STD-7935A. the End User Manual is 
a structured document with specific information to be included under each numbered 
paragraph. The numbering scheme, the contents of each paragraph, and the information 
contained in each paragraph is strictly laid out and must be followed to conform to the 
Standard. The following is an extraction of this Standard. If documentation developers 
are unclear about the nature of the information to be included under each paragraph 
heading, the actual DoD-STD-7935A should be consulted and used in this effort. 

You will notice that Sections 1 through 3 of the End User Manual, Table of 
Contents, DoD-STD-7935A, address the important generalities of the system where as 
Section 4. Processing Reference Guide provides the End User with the necessary 
processing procedures of the business If the procedures are complicated or extensive, 
the Standard suggests that additional sections be added using the same paragraph structure 
as in Section 4. 


SECTION 1. GENERAL 

1.1 Punxjse of the End User Manual. This paragraph describes the purpose of the End 
User Manual either in the following words or modified if appropriate; 

"The objective of the End User Manual for (Project Name) (Project Number) is to 
provide the end user with the information necessary to use the system effectively, 
including operation of (identification of terminal or personal computer) equipment." 

1.2 Purpose of the System. This paragraph states the purpose of the system, the specific 
objectives to accomplish the mission, the expected benefits and the major functions of 
the application. 

1.3 References. Identify other documents which the end user may need in 
accomplishing tasks and procedures. Specify the name of the document, author or 
source, reference number, title, date and security classification, if any. 

a. Project Request. Indicate the project proponent and a reference to the 
Structured Requirements Analysis Planning (STRAP) report or other documentation that 
initiated the project. 

b. Hardware documentation such as that addressing setup, jwwerup and 
powerdown, packing for relocation, activation operation or maintenance. 
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c. Software documentation of an ojserating system, utility software or documents 
oriented to an end user for related systems. References to methodologies could be listed 
in this section. An example’s the IDEF Modeling Techniques Workshop Participant 
Workbook . D. Appleton Company. Inc.. 1986, 1987 and 1988. 

d. Previously published documentation on the project if needed for accomplishing 
the end user's tasks. An example might be a reference to the Functional Description of 
the project. 

1.4 Terms and Abbreviations. Either include a list or reference an appendix of terms, 
definitions and acronyms unique to this document. 

1.5 Security. Under this paragraph, an of)ening sentence stating that precautions have 
been taken to protect the hardware, software and data of the system (name). Then cite 
the following kinds of security precautions addressed: 

a. Assignments of User IDs and Passwords to access the hardware and any user 
account reporting requirements. 

b. Assignments of User Names and Passwords to control access to the software. 
Describe how access levels vary. For instance, you may want to indicate that access 
levels vary, depending on whether the user is restricted to search and retrieval activities, 
data entry, interactive retrieval and update or ad-hoc queries and reports. 

c. A statement of how data integrity is assured, and how error checking/correcting 
procedures and data backup procedures are employed. 

d. A statement to the affect that regulations regarding the unauthorized disclosure 
or use of User IDs, User Names or Passwords are to be applied to all such items 
assigned to the user. In addition, the user must comply with all privacy requirements. 
Unauthorized copying of data, documents or software is prohibited. 
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SECTION 2. SYSTEM SUMMARY 


2.1 Overx ieu . This section provides a nontechnical presentation of information on the 
overall system. Detailed technical information should be presented in other sections. 

2.1.1 Application Summary'. This paragraph explains the uses of the application 
and the user activities which it supports. It describes the main functions performed by 
the system showing: 

a. The logical parts of the system from the end user s viewpoint. 

b. The communication'^ paths and techniques. 

c. The interfaces to other systems. 

d. The organizations that provide input to the system or receive output from it. 

2.1.2 Performance. Describe the overall system performance capabilities, such 
as times and capacits constraints, which the end user can expect in accomplishing major 
functions. 

2.1.3 Controls. This paragraph briefly describes the supervisory controls 
necessary to manage or audit the system. 

2.2 System Environment. This paragraph describes the configuration of the hardw-are 
and software necessary to support the system. An overview of the host or LAN 
configuration is provided, but more detail is needed for workstation configurations. 

2.2.1 Hardware Required. This paragraph identifies and describes the hardware 
required to run the system. 

2.2.2 Software Required. This paragraph identifies and discusses software 
capabilities necessary to use the system. It includes software components developed for 
the application as well as the operating system, utilities and other supporting systems. 

2.3 Contingencies and Alternate Modes of Operation. This paragraph includes a 
statement as to what the user may expect in systems operations during emergencies, 
wartime or conditions of alert. 

2.4 Assistance and Problem Reporting. This section describes online or manual help 
features, and identifies points of contact or other resources and procedures to assist the 
user when problems are encountered. 
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SECTION 3. ACCESS TO THE SYSTEM 


3.1 First-Time Use of the System, This section is intended to describe detailed step-by- 
step procedures oriented to the first-time/occasional end user. Enough detail should be 
presented so that the end user can reliably access the system even before learning the 
details of its functional capabilities. 

3.1.1 Equipment Familiarization. This paragraph describes the following kinds 
of features, as appropriate: 

a. Procedures for turning power on and making any adjustments. 

b. Visual display screen capabilities. 

c. How to identify, position and use the cursor. 

d. Keyboard layout, function keys, and pointing devices such as a mouse. 

e. Procedures for turning power off and any special sequencing operations 
required. 

3.1.2 Access Control. This paragraph gives an overview of system access and 
security features visible to the end user, such as: 

a. How to obtain a password; who to contact: which form to submit. 

b. How the user can change, add or delete a password. 

c. Confidentiality - security and privacy considerations regarding storage and 
various output media generated by the end user. 

3.1.3 Installation and Setup . This paragraph shall describe any special procedures 
which the end user must perform in order to be identified or authorized to access or 
install software on the equipment, or to enter parameters for AIS operation. 

3.2 Initiating a Session. This paragraph provides the end user with step-by-step 
procedures on how to begin work. Also include a problem checklist for difficulties 
encountered. 

3.3 Stopping and Suspending Work. This section describes how the user can interrupt 
or stop the system. 
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ECTION 4. PROCESSING REFERENCE GUIDE 

This section shall provide the end user with technical information on processing. 
DoD-STD-7935A advises that if the procedures are complicated or extensive, additional 
sections 5, 6, ... may be added using the same paragraph structure as used in section 4. 
The Standard states on page 88 that the organization of the document will depend on the 
characteristics of the AIS being documented. For example, if the tasks of end users vary 
depending upon the organization echelon in which they work. Section 4 might be oriented 
to headquarters functions and Section 5 to remote site functions. 

SECTION 4. PROCESSING REFERENCE GUIDE MENUS USED IN THE 
SYSTEM 

4.1 Capabilities. This paragraph provides an overvie\v of the use of the system 
describing menus, functions, transactions and their interrelationships. 

4.2 Conventions. This paragraph describes the conventions used, such as rules for 
assigning names or codes, abbreviations, colors on the screens and use of audible alarms. 

4.3 Processing Procedures - MENUS 

NOTE: Detailed procedures are intended to be presented in the subparagraphs of 
paragraph 4.3. Depending on the design of the AIS, the subparagraphs might be 
organized on a function-by-function basis or on a menu-by-menu basis. For a 
transaction-oriented system the organization might be on a screen-by-screen basis. 

4.3.1 Variable Title (Identify). The title of this paragraph shall identify the 
function, menu, transaction or other process being described. This paragraph shall 
describe and give examples of menus, data entry forms, outputs, diagnostic messages or 
alarms and help facilities which can provide online descriptive or tutorial information. 
The format for presenting this information can be adapted to the particular characteristics 
of the AIS, but a consistent style of presentation must be used, i.e., the descriptions of 
menus must be consistent, the descriptions of transactions must be consistent among 
themselves. 

4.3.2 Variable Title (Identify). This paragraph shall describe the second function, 
menu or other procedure using the same format for information as used in paragraph 
4.3.1. Additional functions, menus or other procedures should be described in 
paragraphs 4.3.3 through 4.3.n. 

4.4 Related Processing. This paragraph shall identify and describe any related batch, 
offline or background processing performed by the AIS that is not invoked directly by 
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the end user and is not described in paragraph 4.3. Any end user responsibilities to 
sup]X)rt this processing will be specified. 

4.5 Recovers' from Errors and Malfunctions. This paragraph shall describe 
responsibilities of the end user for making and retaining all recorded data which can be 
used to replace primary copies of data in event of errors, defects, malfunctions or 
accidents. Step-by-step procedures shall be described as necessary. 

4.6 Messages. This paragraph shall list, or refer to an appendix w'hich lists all error 
messages, diagnostic messages and information messages which can occur while 
accomplishing any of the end user's functions described in paragraphs 4.3 through 4.6. 
The normal corrective action that should be taken after any such message should be 
identified and described. 

Continuing with this example, section 5 would be as follows: 

SECTION PROCESSING REFERENCE GUIDE - COMMAND LANGUAGE 
USED IN SV.STEM 


Then the same paragraph structure as section 4 would be followed for items 5.1 through 
5.6: 

5.1 Capabilities. 

5.2 Conventions. 

5.3 Processing Procedures - COMM.AND LANGUAGE 

etc. 

SECTION 6. PROCESSING REFERENCE GUIDE - GUIDE TO FUNCTIONS 

6.1 Cap T bilities. 

6.2 Conventions. 

6.3 Processing Procedures - FUNCTIONS 

etc. 
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4. MANUAL PREPARATION 


There are two distinct stages in preparing the End User Manual: 

1. A Draft End User Manual is prepared for the Alpha Test of the 
application developed. 

2. An Integrated End User Manual is compiled for the Beta Test and 
Deployment. 

Draft documentation should evolve throughout the INTERACTIVE- 
APPLICATION-DEVELOPMENT activity. As each component of the application is 
completed and unit tested, an application developer or documentation specialist prepares 
draft documentation for peer reviews. If the application developed is complex with a 
fairly large number of people performing narrow sets of functions, it may be practical 
to issue separate sections of the manual for each type of user (e.g., administrative, 
engineers, project managers, etc.). This documentation is updated and consolidated for 
the Alpha Test. Copies of the Draft End User Manual are made for the Alpha Test 
Team, the IPR Team, the Development Team and other interested parties. It is not a 
formal publication. 

Following the Alpha Test, corrections and various required modifications are made 
to produce an End User Manual for the Beta Test. The Beta Test will be testing the end 
user documentation as well as the application itself. 

If the application developed is an extension or additional enhancement of a previous 
project, an Integrated End User Manual is compiled following the Alpha Test. Since the 
Beta Test is for a "live" environment, existing documentation for the business process 
should be integrated with the new documentation. 

5. PACKAGLNG OF THE ENT) USER MANUAL 

The End User Manual should be a 3-ring binder type, with divider tabs for all 
major sections and appendices. 

6. MAINTENANCE OF END USER MANUAL 

The creation and maintenance of the End User Manual should be the responsibility 
of the Application Development Team until transition of the application to the support 
group for deployment. At this time, maintenance responsibilities should be transferred 
to the support agency. 
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APPENDIX C 


BILATERAL NSS USER MANU AL 

Section 1, General 

1.1 Purpose of the End User Manual. The objective of the End User Manual for 
the Bilateral Negotiation Support System (NSS) is to provide the end user with the 
information necessary to use the system effectively, including operation under the 
Microsoft Windows 3.0 environment. 

1.2 Purpo.se of the System. The purpose of the Bilateral NSS is to assist one or 
two negotiators in achieving an equitable solution to a negotiation problem. Each 
negotiation session allows the user to enter issues, weights and utilities associated with 
each issue. After receiving inputs from both negotiators, the program will calculate and 
display the results in both tabular and graphical formats. Users also can modify any 
input variables and perform "what-if analysis to see any effects on the final results. 

1.3 References. Further information on NSS theory and W'indow's 3.0 operation 
may be obtained from: 

a. Bui, T. and Sivasankaran, T., "Fuzzy Preferences in Bilateral Negotiation 
Support Systems", 24th Annual Hawaii International Conference on System Sciences, 
January 8-11, 1991, pp. 687-694, IEEE Computer Society Press. 

b. Bui, T., Co-op: A Group Decision Support System for Cooperative 
Multiple Criteria Group Decision-Making, Springer-Verlag, Berlin, 1987. 
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c. Microsoft Windows User's Guide, version 3.0. Microsoft Corporation, 

K>^0. 

1.4 Terms and Abbreviations. All terms and abbreviations unique to the Bilateral 
NSS are explained in the applicable sections of the manual. Additional Windows 3.0 
terminology may be obtained from the glossary section of the Windows User's Guide. 

1.5 Security. Password protection is provided for all user sensitive information. 
The 5 character password is non-modifiable once entered. A dialog box requesting user 
confirmation is presented for all operations that would overwrite any existing files. 

Section 2. System Summary 

2.1 Overview. The Bilateral NSS is a software program based on multiple 
attribute utility theory and the concept of joint utility. Although not required, the 
following procedure is normally used to operate the program: 

a. Identify a common set of issues about which the parties disagree. 

b. Define the range of values for each issue by assigning initial offers. 

c. Prioritize each issue by assigning relative weights to them. 

d. Within the range of values for each issue assign utility values. 

e. Compute joint utility curves by combining the utility functions of each 

party. 

f. Observe negotiation results and modify user variables to search for better 
solutions. 
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2.2 System Environment. 


2.2.1 Hardware Required. This program will operate on any IBM 
compatible PC with at least 640K of Random Access Memory (RAM). A hard disk is 
not required. 

2.2.2 Software Required. This program requires DOS 3.1 or higher and the 
Microsoft Windows 3.0 operating system to run. Additionally, two dynamic link 
libraries (DLL) called VBRUN100.DLL and VBTOOLS.VBX must be located in any 
directory in your path. 

2.3 Contingencies and Alternate Modes of Operation. N/A 

2.4 Assistance and Problem Reporting. An on-line help system is available at all 
times. To bring up the main help screen select the Index command from the Help menu 
on the main screen. The main help screen contains help on ten subject areas. Select the 
button to the left of the subject area that you want help on and press the Get Help button. 

To get context sensitive help during the program just press the "?” button on the 
bottom right comer of any screen. 

Section 3. Access to the System 

3.1 First-Time Use of the System. Follow the steps below to start the program: 
a. From the Windows Program Manager screen select the Run command 
under the File Menu. 
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b. Tyf)e "nss" in the text box provided if the nss.exe file is in your path. 
If nss.exe is not in your path then you must type in the entire pathname. Press Enter and 
the Bilateral NSS opening screen will appear. 

c. If you want help with the program before starting, simply select the Index 
command under the Help Menu. A help screen will appear with instructions on how to 
use the program. 

d. To begin a new negotiation session, follow the steps in paragraph 3.2 
below. On-line help is available at all times by selecting the "?" button located at the 
bottom of each screen. 

3.2 Initiating a Session. Follow the steps below to start a new negotiation session: 

a. Select the Start Nev\ Session command under the File Menu. 

b. Type a filename (up to 8 characters) to save your work under then press 
the OK button. 

c. Enter your name, party and a 5 character password in the spaces 
provided. Don't forget your password since once it is entered it cannot be changed. 
Press the OK button to continue. 

d. The Main Selection Menu will appear with the top two options available. 
The last three options are not available (shown as grayed out text) until both parties have 
entered initial starting offers for each issue. Select the Issue Parameters option and press 
the OK button to continue. 

e. The Issue Parameters screen has three entries for each issue - Issue 
Name, Unit Value and Initial Starting Offer. Issue names can be up to 15 characters 
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long The Unit V'aJue (up to 7 characters) is the unit of measure for an issue — e.g., 
dollars, years, etc. Initial starting offers (0 to 30000) can be entered directly into the 
text box or selected by using the scroll bars beside each issue. 

f. To add a new issue just press the Add New Issue button at the bottom of 
the screen. Likewise, to delete an issue press the Delete Issue button and enter the 
number of the issue you want to delete. Once you are done press the OK button to 
accept your entries. 

g. Once both parties have entered initial starting offers the last three options 
on the Main Selection Menu will be available. Select the Issue Priority option and press 
the OK button. At this point a password screen will appear asking you to enter your 
password. Type in your character password and press Enter (the program is case 
sensitive so capitalize any letters you did when you initially entered it). 

h. The next screen gives you three choices for ranking each issue -- equal 
weighting, direct prioritization and pairwise comparison. Select your choice and follow 
the instructions. After completing your rankings you will be returned to the Main 
Selection Menu. 

i. Select the Utility Values option and press the OK button. You will again 
be requested to enter your password. 

J. The Utility Value screen lists all session issues on the left side and the 
seven utility values for the currently active issue on the right side. To enter utility values 
follow this procedure: 

1. Click the option button to the left of any issue you want to update. 




2. At the bottom of the utility graph are the seven range points for that 
issue. Above each range point is a column of utility values from 0 to 100. Select a 
utility value for each range f)oint (0 being no utility and 100 being maximum utility). 

3. Repeat steps 1 and 2 for each issue. Press the OK button to accept 
your data and return to the Main Selection Menu. 

k. To view the results of the negotiation at this point select the Negotiation 
Results option and press the OK button. The Negotiation Results screen will appear. 

l. The Negotiation Results screen displays three sets of tabular data - highest 
joint utility, mid-point utility and relative importance utility. Additionally, there is a 
Scratch Pad that allows you to enter any range point (the green Descriptor column) to 
observe how the individual pany and total utility values will be affected. 

m. To print out the results on the screen press the Print button. To save the 
screen results as an ASCII text file press the Save button. To view the results 
graphically press the Display Graphs button at the bottom of the screen. 

n. The Graphs screen allows you to view the weighted or unweighted results 
of any issue. Just select the issue from the list at the left of the screen and select either 
the Weighted or Unweighted option button below it. 

o. To quit the current session and save your work just press the Quit button 
on the Main Selection Menu and follow the instructions. 

3.3 Stopping and Suspending Work. You may quit the current session you are 
working on at any point. If you are in the middle of entering data press the OK button 
for that screen if you want to update those entries. After returning to the Main Selection 
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Menu press the Quit button and a Save screen will appear. If you want to save your 
newly entered data and overwrite the old file just press the Save button. Otherwise, 
press the Cancel button. At this point you can start a new session or open a prior one. 

To save your work without going through the Main Selection Menu just select the 
File Menu on the Bilateral NSS main screen and select the Save or Save As commands. 
The Save command w ill allow you to save your data under the current session name and 
Save As will let you save your data under any filename. 

To quit the Bilateral NSS program select the Exit Program command under the File 
Menu and follow the prompts. 

Section 4. Processing Reference Guide - Menus 

4.1 Processing Procedures - Menus. There are two menus associated with the 
opening Bilateral NSS screen -- File and Help. 

4.1.1 File Menu. There are five commands under the File Menu: 

4.1.1.1 Start New Session. This command is selected to start a new 
negotiation session. A dialog box will appear requesting a filename to save your data 
under. 

4.1.1.2 Open Prior Session. This command is selected to open a 
previous negotiation session. A dialog box will appear that allows you to browse through 
any drive and directory for a prior session’s data. Only filenames with a .nss extension 
will be shown in the file list box. 

4.1.1.3 Save Current Session. This command is selected to save the 
current negotiation data under the currently active filename. A dialog box will appear 
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that asks you if you want to save the data under the current name. Select Save to store 
the data or Cancel to abort the command. 

4.1 ■ 1,4 Save Current Session As. This command is selected to save the 
current negotiation data under any user entered filename. A dialog box will appear that 
allows you to enter any filename up to 8 characters long. Select Save to store the data 
or Cancel to abort the command 

4,1.1,5 Exit Program. This command is selected to end the Bilateral 
NSS program. A dialog box will appear that allows you to save the current negotiation 
data under the currently active filename. Select Save to exit the program after saving the 
latest negotiation data or Cancel to exit the program without saving the latest data. 
4.1.2 Help Menu. There are two commands under the Help Menu: 

4.1.2.1 Index. This command is selected to bring up the main help 
menu. A screen will appear that explains the help system and allows the user to select 
from a menu of ten subject areas. 

4.1.2.2 About... This command brings up the Bilateral NSS credit 

screen. 

Section 5. Processing Reference Guide - Procedures 

5.1 Starting a New Negotiation Session. To begin a new session select the Start 
New Session command under the File Menu and follow the procedures below; 

a. Enter any filename up to 8 characters in the text box provided. Press the 
OK button to continue. 
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b. Next, enter your name, party and a 5 character password in the textboxes 
provided. Don’t forget your password since once it is entered you can’t change it. Press 
the OK button to continue. 

c. When the Main Selection Menu is displayed select the Issue Parameters 
option and press the OK button. 

d. Enter up to 10 issues and an initial starting value using the scroll bars 
next to each issue. A ne\\ issue may be added by clicking on the Add Nev\ Issue button 
at the bottom of the screen. To delete an issue click on the Delete Issue button. 

e. Once both panics have entered initial starting values you can enter your 
weightings and utilities by selecting the appropriate option from the Main Selection 
Menu. 

f. Selecting the Negotiation Results option from the Main Selection Menu 
will give you a tabular display of the results of the current session. Clicking on the 
Display Graphs button at the bottom of the screen will display the issues in graphical 
form. 

5.2 Opening a Prior Negotiation Session. To open a prior negotiation session 
select the Open Prior Session command from the File Menu and follow the procedures 
below" 

a. A dialog box will appear with three list boxes to let you select which 
drive or directory to search in. Double clicking on a directory in the directory list box 
will make that your default directory. Only filenames with a .nss extension will be 
shown. 
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b. To select a file either double click on the filename or press the OK button 
after clicking once on the filename. 

c. After selecting the file, the Main Selection Menu will appear. You can 
then select any option that is not grayed out. 

5.3 Saving a Negotiation Session. To save a negotiation session select the Save 
Current Session command under the File Menu and follow the procedures below; 

a. A dialog box will appear asking you whether you want to save the current 
data using the filename you entered when you started the session. 

b. Press the OK button to save your data or press the Cancel button to retum 
to the previous screen. Remember that selecting OK will overwrite any previous data 
you may have stored in that file. 

5.4 Saving a Negotiation Session Under a Different Name. To save a negotiation 
session under a different name select the Save Current Session As command under the 
File Menu and follow the procedures below ; 

a. Enter the name you want to save your data under in the text box provided. 
A filename can consist of any combination of letters and numbers up to eight characters. 
The filename will automatically be given a .nss extension. 

b. Press the Save button to save your data or tlie Cancel button to retum to 
the previous screen. Remember that selecting Save will overwrite any previous data you 
may have stored in that file. 

5.5 Using the Main Selection Menu. There are five selection options for each 
party. They are; 
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a. Issue Parameters - this option allows either party to add or delete issues. 
Initial starting offers are also entered on this screen. 

b. Name or Party - this option allows either party to enter or change their 
name or party data. If this is the party 's first entry for the session they will also enter 
a five character password. 

c. Issue Priorities - this option allows either party to adjust the weighting 
given to each issue, 

d. Utility Values - this option allows either party to enter or update the 
utilities assigned to each issue. 

e. Negotiation Results - this option allows either party to view the results of 
the current negotiation session. A Scratch Pad is provided to allow a party to perform 
"what-if" analysis on the results. 

1. Pressing the Display Graphs button brings up a screen that allow's you 
to view the results in graphical form. Both weighted and unweighted results can be 
viewed. 

2. Pressing the Save or Print buttons will send the negotiation results in 
ASCII form to the disk or printer, respectively. 

5.6 Entering/Changing Party Data. To enter or change party data select the Name 
or Party option from the Main Selection Menu and follow the procedures below: 

a. If you are entering this data for the first time a dialog box will appear 
with empty textboxes for name, party and password. 
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b. Enter up to 15 characters for your name and party. Your password must 
be five characters long and can consist of any combination of letters and numbers. Don't 
forget this password since once it is accepted it can not be changed. 

c. If you are updating previously entered information a dialog box requesting 
your password will appear. Enter your password and press Enter. 

d. Change the name or party information in the textboxes provided and select 
OK when you are done. 

5.7 Entering Issue Parameters. 

a. Three types of data are entered for each issue; 

1. Issue Name - (max. of 15 characters) 

2. Unit Value - (max. of 7 characters) the unit of value that describes 
the issue. For example, if contract length was an issue, then the unit value might be 
years. 

3. Initial Starting Offer - (range 0 to 30,000) the starting value that you 
propose for this issue. To use the scroll bars click the outer arrows to increment the 
value by one and the inside of the scroll bars to increment by 25. 

b. To add a new issue press the Add New Issue button and a new' set of 
textboxes will appear. 

c. To delete an issue press the Delete Issue button and enter the number of 
the issue you want to delete. 

d. You can enter a maximum of ten issues in each session. 





5.8 Entering Issue Priorities. 

a. There are three ways of assigning issue priorities: 

1. Equal Prioritization - all issues are assigned a weighting equal to \I{P 
of issues). If equal priority is chosen the program w'ill calculate the w'eighting and 
display it in a message box. 

2. Direct Prioritization - the user can enter an individual weighting value 
for each issue. If direct priority is chosen a screen will be displayed that allow s you to 
select a weighting value for each issue. Allowable values are between 0 and 10. 

3. Pairwise Comparison - the user indirectly chooses a weighting value 
b> comparing the issues to each other in pairs. If pairwise comparison is chosen a 
screen will be displayed that asks you to select between two issues at a time. This 
process w ill be repeated for all possible combinations of issues. The program will then 
calculate the proper weightings, (not available in version 1.0) 

5.9 Entering Utility Values. After selecting the Utility Values option from the 
Main Selection Menu a screen will be displayed that allows you to enter your utility 
values for each issue. 

a. There are seven evenly separated range points associated with each issue. 
The range for each issue is bounded by the initial starting offer of each party. 

b. To enter utility values select an issue from those available in the leftmost 

box. 
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c. For each of the issue’s seven range points, click a utility button that best 
describes your desirability for that point. Utility values range from 0 to 100 (0 being no 
utility and 100 being maximum utility). 

d. Repeat steps b and c for all issues. 

e. After entering all the utility values select the OK button. 

5.10 Displaving/Modifying Negotiation Results. 

a. Select the Negotiation Results option from the Main Selection Menu. 

b. From the Negotiation Results screen you have four choices: 

1. Display issue graphs using the Display Graphs button. 

2. Save the results of the current screen in ASCII text format using the 

Save button. 

3. Print the results of the current screen to the active printer using the 

Print button. 

4. Do "what-if" analysis on the current results using the Scratch Pad 
portion of the screen. 

c. To do "what-if analysis click on any of the green Descriptor Value 
boxes. Enter any value desired that is within the range for that issue. 

d. Press the Enter key on your keyboard and observe the newly calculated 
utility values for each party. Also note the change in total utility at the bottom of the 
screen. 

e. Scratch Pad values initially default to the highest joint utility values. 
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5.11 Displaying Graphs. To view the graphs for each issue you must first select 
the Negotiation Results option from the Main Selection Menu. 

a. Press the Display Graphs button on the Negotiation Results screen. 

b. Once the Graphs screen is displayed you can select an issue in the 
leftmost box. 

c. The initial screen default displays the graphs using weighted values. To 
select unweighted values you must click on the unweighted option button at the bottom 
of the screen. 
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